idnits 2.17.00 (12 Aug 2021) /tmp/idnits40604/draft-ietf-pwe3-p2mp-pw-03.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 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 27, 2011) is 3858 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) == Outdated reference: draft-ietf-l3vpn-2547bis-mcast-bgp has been published as RFC 6514 == Outdated reference: draft-ietf-pwe3-p2mp-pw-requirements has been published as RFC 7338 == Outdated reference: draft-ietf-mpls-p2mp-lsp-ping has been published as RFC 6425 == Outdated reference: draft-ietf-l2vpn-vpls-mcast has been published as RFC 7117 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). 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: April 15, 2012 Cisco Systems 7 Frederic Jounay Maciek Konstantynowicz 8 Philippe Niger Juniper 9 France Telecom 11 Thomas D. Nadeau Gianni Del Vecchio 12 CA Technologies Swisscom 14 Simon Delord Yuji Kamite 15 Telstra NTT Communications 17 Laurent Ciavaglia Lizhong Jin 18 Martin Vigoureux ZTE 19 Alcatel-Lucent 20 October 27, 2011 22 Signaling Root-Initiated Point-to-Multipoint Pseudowire using LDP 23 draft-ietf-pwe3-p2mp-pw-03.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 April 27, 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. Group ID usage...........................................11 64 3.4. Generic Label TLV........................................11 65 3.5. Transport LSP TLV........................................12 66 4. LDP Capability Negotiation....................................13 67 5. P2MP PW Status................................................15 68 6. Security Considerations.......................................15 69 7. IANA Considerations...........................................15 70 7.1. FEC Type Name Space......................................15 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 8. Acknowledgment................................................17 75 9. References....................................................17 76 9.1. Normative References.....................................17 77 9.2. Informative References...................................18 78 Full Copyright Statement.........................................21 79 Intellectual Property Statement..................................21 81 1. Introduction 83 A Point-to-Multipoint (P2MP) Pseudowire (PW) emulates the 84 essential attributes of a unidirectional P2MP Telecommunications 85 service such as P2MP ATM over PSN. A major difference between a 86 Point-to-Point (P2P) PW outlined in [RFC3985] and a P2MP PW is that 87 the former is intended for bidirectional service whereas the latter 88 is intended for both unidirectional and bidirectional services. 89 Requirements for P2MP PW are described in [P2MP-PW-REQ]. 91 A P2MP PW can be constructed as either Single Segment (P2MP SS-PW) 92 or Multi Segment (P2MP MS-PW) Pseudowire as mentioned in [P2MP-PW- 93 REQ]. P2MP MS-PW is outside the scope of this document. A reference 94 model for P2MP PW is depicted in Figure 1 below. A transport LSP 95 associated with a P2MP SS-PW SHOULD be a P2MP MPLS LSP (i.e., P2MP 96 TE tunnel established via RSVP-TE [RFC4875] or P2MP LSP established 97 via mLDP [mLDP]) spanning from the Root-PE (R-PE) to the Leaf-PE(s) 98 (L-PEs) of the P2MP SS-PW tree. For example, in Figure 1, PW1 can be 99 associated with a P2MP TE tunnel or P2MP LSP setup using [mLDP] 100 originating from T-PE1 and terminating at T-PE2 and T-PE3. 102 Mechanisms for establishing P2P SS-PW using LDP are described in 103 [RFC4447]. In this document, we specify a method to signal P2MP PW 104 using LDP. In particular, we define new TLVs, parameters, and status 105 codes to facilitate LDP to signal and maintain P2MP PWs. 107 |<--------------P2MP PW---------------->| 108 Native | | Native 109 Service | |<--PSN1->| |<--PSN2->| | Service 110 (AC) V V V V V V (AC) 111 | +-----+ +------+ +------+ | 112 | | | | P1 |=========|T-PE2 |AC3 | +---+ 113 | | | | .......PW1.........>|-------->|CE3| 114 | |T-PE1|=========| . |=========| | | +---+ 115 | | .......PW1........ | +------+ | 116 | | . |=========| . | +------+ | 117 | | . | | . |=========|T-PE3 |AC4 | +---+ 118 +---+ |AC1 | . | | .......PW1.........>|-------->|CE4| 119 |CE1|------->|... | | |=========| | | +---+ 120 +---+ | | . | +------+ +------+ | 121 | | . | +------+ +------+ | 122 | | . |=========| P2 |=========|T-PE4 |AC5 | +---+ 123 | | .......PW1..............PW1.........>|-------->|CE5| 124 | | |=========| |=========| | | +---+ 125 | +-----+ +------+ +------+ | 127 Figure 1: P2MP PW 129 As outlined in [P2MP-PW-REQ], even though the traffic flow from an 130 R-PE to L-PEs is P2MP in nature, it may be desirable for any L-PE to 131 send unidirectional P2P traffic destined only to the R-PE. The 132 proposed mechanism takes such option into consideration. 134 A P2MP PW requires an MPLS LSP to carry the PW traffic, and the MPLS 135 packets carried over the PW will be encapsulated according to the 136 methods described in [RFC5332]. 138 Conventions used in this document 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in RFC-2119 [RFC2119]. 144 2. Terminology 146 FEC: Forwarding Equivalence Class 148 LDP: Label Distribution Protocol 150 mLDP: Label Distribution Protocol for P2MP LSP 152 LSP: Label Switching Path 154 MS-PW: Multi-Segment Pseudowire 156 P2P: Point to Point 158 P2MP: Point to Multipoint 160 PE: Provider Edge 162 PSN: Packet Switched Network 164 PW: Pseudowire 166 SS-PW: Single-Segment Pseudowire 168 S-PE: Switching Provider Edge Node of MS-PW 169 TE: Traffic Engineering 171 R-PE: Root-PE - ingress PE, PE initiating P2MP PW setup. 173 L-PE: Leaf-PE - egress PE. 175 3. Signaling P2MP PW 177 In order to advertise labels as well as exchange PW related LDP 178 messages, PEs must establish LDP sessions among themselves using the 179 Extended Discovery Mechanisms. A PE discovers other PEs that are to 180 be connected via P2MP PWs either via manual configuration or 181 autodiscovery [RFC6074]. 183 R-PE and each L-PE MUST be configured with the same FEC as defined 184 in the following section. 186 P2MP PW requires that there is an active P2MP transport LSP set up 187 between R-PE and L-PE(s). The procedure to set up the P2MP transport 188 LSP is different depending on the protocol used (RSVP-TE or mLDP). 190 In case of mLDP, an L-PE can decide to join the P2MP LSP at any 191 time, while in the case of RSVP-TE the P2MP transport LSP is set up 192 by the R-PE, generally at the initial service provisioning time. It 193 should be noted that local policy can override any decision to add 194 or prune existing or new L-PE(s) to/from the tree. In any case, the 195 PW setup can ignore these differences, and simply assume that the 196 P2MP transport LSP is available when needed. 198 A P2MP PW signaling is initiated by the R-PE simply by sending a 199 P2MP-PW LDP label mapping message to the L-PE(s) belonging to that 200 P2MP PW. This label mapping message will contain the following: 202 1. A P2MP Upstream PW FEC element. 203 2. An Interface Parameters TLV, as described in [RFC4447]. 204 3. A PW Grouping TLV as described in [RFC4447]. 205 4. A Transport LSP TLV. 206 5. A label TLV for the upstream-assigned label used by R-PE 207 for the traffic going from R-PE to L-PE(s). 209 The R-PE imposes the upstream-assigned label on the outbound packets 210 sent over the P2MP-PW, and using this label an L-PE identifies the 211 inbound packets arriving over the P2MP PW. 213 Additionally, the R-PE MAY send label mapping message(s) to one or 214 more L-PE(s) to signal unidirectional P2P PW(s). The L-PE(s) can use 215 such PW(s) to send traffic to the R-PE. This optional label mapping 216 message will contain the following: 218 1. P2P Downstream PW FEC element. 219 2. A label TLV for the down-stream assigned label used by the 220 corresponding L-PE to send traffic to the R-PE. 222 The LDP liberal label retention mode is used, and per requirements 223 specified in [RFC5036], the label request message MUST also be 224 supported. 226 The upstream-assigned label is allocated according to the rules in 227 [RFC5331]. 229 When an L-PE receives a PW Label Mapping Message, it MUST verify 230 that the associated P2MP transport LSP is in place. If the 231 associated P2MP transport LSP is not in place, and its type is LDP 232 P2MP LSP, the L-PE SHOULD attempt to join the P2MP LSP. If the P2MP 233 transport LSP is not in place, and its type is RSVP-TE P2MP LSP, the 234 L-PE SHOULD wait till the P2MP transport LSP is signaled. 236 3.1. PW ingress to egress incompatibility issues 238 If an R-PE signals a PW with a pw type, CW mode, or interface 239 parameters that a particular L-PE cannot accept, then the L-PE must 240 not enable the PW, and notify the user. In this case, a PW status 241 message of 0x00000001 (Pseudowire Not Forwarding) MUST also be sent 242 to the R-PE. 244 Note that this procedure does not apply if the L-PE had not been 245 provisioned with this particular P2MP PW. In this case according to 246 the LDP liberal label retention rules, no action is taken. 248 3.2. P2MP PW FEC 250 [RFC4447] specifies two types of LDP FEC elements called "PWid FEC 251 Element" and "Generalized PWid FEC Element" used to signal P2P PWs. 252 We define two new types of FEC element called "P2MP Upstream PW FEC 253 Element" and "P2P Downstream PW FEC Element". These FEC elements are 254 associated with a mandatory upstream assigned label and an optional 255 downstream assigned label respectively. 257 FEC type of the P2MP Upstream PW FEC Element is 0x82 (pending IANA 258 allocation) and is encoded as follows: 260 0 1 2 3 261 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 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 |FEC Type = 0x82|C| PW Type | PW Info Length| 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | AGI Type | Length | AGI Value | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 ~ AGI Value (contd.) ~ 268 | | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | AII Type | Length | SAII Value | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 ~ SAII Value (contd.) ~ 273 | | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 |0|0| Transport LSP TLV (0x0971)| Length | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Reserved |PMSI Tunnel Typ| Transport LSP ID | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 ~ Transport LSP ID (contd.) ~ 280 | | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | | 283 | Optional Parameters | 284 ~ ~ 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 Figure 2: P2MP Upstream PW FEC Element 289 * PW Type: 291 15-bit representation of PW type, and the assigned values are 292 assigned by IANA. 294 * C bit: 296 A value of 1 or 0 indicates whether control word is present or 297 absent for the P2MP PW. 299 * PW Info Length: 300 Sum of the lengths of AGI, SAII and Optional Parameters field in 301 octets. If this value is 0, then it references all PWs using the 302 specified grouping ID. In this case, there are neither other FEC 303 element fields (AGI, SAII, etc.) present, nor any interface 304 parameters TLVs. 306 * AGI: 308 Attachment Group Identifier can be used to uniquely identify VPN 309 or VPLS instance associated with the P2MP PW. This has the same 310 format as the Generalized PWid FEC element [RFC4447]. 312 * SAII: 314 Source Attachment Individual Identifier is used to identify the 315 root of the P2MP PW. The root is represented using AII type 2 316 format specified in [RFC5003]. Note that the SAII can be omitted 317 by simply setting the length and type to zero. 319 P2MP PW is identified by the Source Attachment Identifier (SAI). 320 If the AGI is non-null, the SAI is the combination of the SAII 321 and the AGI, if the AGI is null, the SAI is the SAII. 323 * Transport LSP TLV: 325 A P2MP PW MUST be associated with a transport LSP. The Transport 326 LSP TLV contains the information required to identify the 327 transport LSP. Transport LSP TLV MUST immediately follow the FEC, 328 but is not part of the FEC, and SHOULD NOT be used in other 329 messages where the FEC is used. 331 * Optional Parameters: 333 The Optional Parameter field can contain some TLVs that are not 334 part of the FEC, but are necessary for the operation of the PW. 335 This proposed mechanism uses two such TVLs: Interface Parameters 336 TLV and Group ID TLV. 338 The Interface Parameters TLV and Group ID TLV specified in 339 [RFC4447] can also be used in conjunction with P2MP PW FEC. For 340 Group ID TLV the sender and receiver of these TLVs should follow 341 the same rules and procedures specified in [RFC4447]. For 342 Interface Parameters TLV the procedure differs from the one 343 specified in [RFC4447] due to specifics of P2MP connectivity. When 344 the interface parameters are signaled by an R-PE, each L-PE must 345 check if its configured value(s) is less than or equal to the 346 threshold value provided by the R-PE (e.g., MTU size (Ethernet), 347 max number of concatenated ATM cells, etc)). For other interface 348 parameters like CEP/TDM Payload bytes (TDM), the value MUST 349 exactly match the values signaled by the R-PE. 351 Multicast traffic stream associated with a P2MP PW can be 352 selective or inclusive. To support the former, this document 353 defines a new optional Selective Tree Interface Parameter sub-TLV 354 (type is pending IANA allocation) according to the format 355 described in [RFC4447]. The value of the sub-TLV contains the 356 source and the group for a given multicast tree as shown in Figure 357 3. This is similar to the way (S, G) is defined in [VPLS-MCAST]. 358 Also, if a P2MP PW is associated with multiple selective trees, 359 the corresponding label mapping message will carry more than one 360 instances of this Sub-TLV. Furthermore, in the absence of this 361 sub-TLV, the P2MP PW is associated with all multicast traffic 362 stream originating from the root. 364 +----------------------------------------- + 365 | Multicast Source Length (1 Octet) | 366 +----------------------------------------- + 367 | Multicast Source (variable length) | 368 +----------------------------------------- + 369 | Multicast Group Length (1 Octet) | 370 +----------------------------------------- + 371 | Multicast Group (variable length) | 372 +----------------------------------------- + 374 Figure 3: Selective Tree Interface Parameter Sub-TLV Value 376 The Multicast Source field contains the address of the multicast 377 source. The Multicast Source field contains an IPv4 address or IPv6 378 address depending on whether the Multicast Source Length is 32 or 379 128. The Multicast Source Length can be set to 0 to indicate 380 wildcard. 382 The Multicast Group field contains the address of the multicast 383 group. The Multicast Group field contains an IPv4 address or IPv6 384 address depending on whether the Multicast Group Length is 32 or 385 128. The Multicast Group Length can be set to 0 to indicate 386 wildcard. 388 Note that since the LDP label mapping message is only sent by an R- 389 PE to all the L-PEs, it is not possible to negotiate any interface 390 parameters. 392 The type of optional P2P Downstream PW FEC Element is 0x83 (pending 393 IANA allocation), and is encoded as follows: 395 0 1 2 3 396 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 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 |FEC Type = 0x83|C| PW Type | PW Info Length| 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | AGI Type | Length | AGI Value | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 ~ AGI Value (contd.) ~ 403 | | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | AII Type | Length | SAII Value | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 ~ SAII Value (contd.) ~ 408 | | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 Figure 4: P2P Downstream PW FEC Element 413 The definition of the fields in the P2P Downstream PW FEC Element is 414 the same as those of P2MP Upstream PW FEC Element. 416 3.3. Group ID usage 418 The Grouping TLV as defined in [RFC4447] contains a group ID capable 419 of indicating an arbitrary group membership of a P2MP-PW. This group 420 ID can be used in LDP "wild card" status, and withdraw label 421 messages, as described in [RFC4447]. 423 3.4. Generic Label TLV 425 As in the case of P2P PW signaling, P2MP PW labels are carried 426 within Generic Label TLV contained in LDP Label Mapping Message. A 427 Generic Label TLV is formatted and processed as per the rules and 428 procedures specified in [RFC4447]. For a given P2MP PW, a single 429 upstream-assigned label is allocated by the R-PE, and is advertised 430 to all the L-PEs using the Generic Label TLV in label mapping 431 message containing the P2MP Upstream PW FEC element. 433 The R-PE MAY also allocate a unique label for each L-PE from which 434 it intends to receive P2P traffic. Such a label is advertised to the 435 L-PE using Generic Label TLV in label mapping message. 437 3.5. Transport LSP TLV 439 A P2MP PW MUST be associated with a transport LSP which can be 440 established using RSVP-TE or mLDP. Thus, a Label Mapping Message 441 MUST contain the identity of the transport LSP. For this purpose, 442 this specification introduces a new TLV called "Transport LSP TLV" 443 which has the following format: 445 0 1 2 3 446 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 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 |0|0| Transport LSP TLV (0x0971)| Length | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Reserved |PMSI Tunnel Typ| Tunnel Identifier | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 ~ Tunnel Identifier (contd.) ~ 453 | | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 Figure 5: Transport LSP TLV 458 Note: TLV number pending IANA allocation. 460 * Reserved Flags: 462 Reserved bits Must be set to 0 when transmitting the message, and 463 ignored on receiving the message. 465 * PMSI Tunnel Type: 467 The Transport LSP Type identifies the type of technology used to 468 establish a transport LSP. The PMSI tunnel type is defined in 469 [L3VPN-MCAST]. 471 When the type is set to mLDP P2MP LSP, the Tunnel Identifier is 472 a P2MP FEC Element as defined in [mLDP]. A new mLDP Opaque Value 473 Element type for L2VPN-MCAST application needs to be allocated. 475 Editor Comment: The content of the Opaque Value Element TLV is a 476 TBD. 478 * Tunnel Identifier: 480 The Tunnel containing the Transport LSP is identified by the 481 Tunnel Identifier which is defined in [L3VPN-MCAST]. 483 Transport LSP TLV MUST be present only in the Label Mapping 484 Message. An R-PE sends Label Mapping Message as soon as the 485 transport LSP ID associated with the P2MP PW is known (e.g., via 486 configuration) regardless of the operational state of that 487 transport LSP. Similarly, an R-PE does not withdraw the labels 488 when the corresponding transport LSP goes down. Furthermore, an 489 L-PE retains the P2MP PW labels regardless of the operational 490 status of the transport LSP. 492 Note that a given transport LSP can be associated with more than one 493 P2MP PWs and all P2MP PWs will be sharing the same R-PE and L-PE(s). 495 In the case of LDP P2MP LSP, when an L-PE receives the Label 496 Mapping Message, it can initiate the process of joining the P2MP LSP 497 tree associated with the P2MP PW. 499 In the case of RSVP-TE P2MP LSP, only the R-PE initiates the 500 signaling of P2MP LSP. 502 4. LDP Capability Negotiation 504 The capability of supporting P2MP PW must be advertised to all LDP 505 peers. This is achieved by using the methods in [RFC5561] and 506 advertising the P2MP PW LDP capability TLV. If an LDP peer supports 507 the dynamic capability advertisement, this can be done by sending a 508 new capability message with the S bit set for the P2MP PW capability 509 TLV. If the peer does not support dynamic capability advertisement, 510 then the P2MP PW TLV MUST be included in the LDP initialization 511 procedures in the capability parameter [RFC5561]. An LSR having P2MP 512 PW capability MUST recognize both P2MP Upstream FEC Element and P2P 513 Downstream FEC Element in LDP Label Binding Message. 515 In line with requirements listed in [RFC5561] the following TLV is 516 defined to indicate the P2MP PW capability: 518 0 1 2 3 519 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 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 |U|F| TLV Code Point=0x703 | Length | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 |S| Reserved | Reserved | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 Figure 6: P2MP PW LDP Capability TLV 528 Note: TLV number pending IANA allocation. 530 * U-bit: 532 SHOULD be 1 (ignore if not understood). 534 * F-bit: 536 SHOULD be 0 (don't forward if not understood). 538 * TLV Code Point: 540 The TLV type identifies a specific capability. The P2MP PW 541 capability code point is requested in the IANA allocation section 542 below. 544 * S-bit: 546 The State Bit indicates whether the sender is advertising or 547 withdrawing the P2MP PW capability. The State bit is used as 548 follows: 549 1 - The TLV is advertising the capability specified by the 550 TLV Code Point. 552 0 - The TLV is withdrawing the capability specified by the 553 TLV Code Point. 555 5. P2MP PW Status 557 In order to support the proposed mechanism, a node MUST be capable 558 of handling PW status. As such, PW status negotiation procedure 559 described in [RFC4447] is not applicable to P2MP PW. 561 Once an L-PE successfully processes a Label Mapping Message for a 562 P2MP PW, it MUST send appropriate PW status according to the 563 procedure specified [RFC4447] to notify the PW status. If there is 564 no PW status notification required, then no PW status notification 565 is sent (for example if the P2MP PW is established and operational 566 with a status of 0x00000000, pw status message is not necessary). PW 567 status message sent from any L-PE to R-PE contains P2P Downstream PW 568 FEC to identify the PW. 570 An R-PE also sends PW status to L-PE(s) to reflect its view of a 571 P2MP PW state. Such PW status message contains P2MP Upstream PW FEC 572 to identify the PW. 574 Connectivity status of the underlying P2MP LSP that P2MP PW is 575 associated with, can be verified using LSP Ping and Traceroute 576 procedures described in [P2MP-LSP-PING]. 578 6. Security Considerations 580 The security measures described in [RFC4447] is adequate for the 581 proposed mechanism. 583 7. IANA Considerations 585 7.1. FEC Type Name Space 587 This document uses two new FEC element types, number 0x82 and 0x83 588 will be requested as an allocation from the registry "FEC Type Name 589 Space" for the Label Distribution Protocol (RFC5036): 591 Value Hex Name Reference 592 ------- ----- ----------------------------- --------- 593 130 0x82 P2MP PW Upstream FEC Element RFCxxxx 594 131 0x83 P2MP PW Downstream FEC Element RFCxxxx 596 7.2. LDP TLV Type 598 This document uses a new LDP TLV types, IANA already maintains a 599 registry of name "TLV TYPE NAME SPACE" defined by RFC5036. The 600 following values are suggested for assignment: 602 TLV type Description: 604 0x0971 Transport LSP TLV 605 0x0703 P2MP PW Capability TLV 607 7.3. mLDP Opaque Value Element TLV Type 609 This document requires allocation of a new mLDP Opaque Value Element 610 Type from the LDP MP Opaque Value Element type name space defined in 611 [mLDP]. 613 The following value is suggested for assignment: 615 TLV type Description 616 0x3 L2VPN-MCAST application TLV 618 7.4. Selective Tree Interface Parameter sub-TLV Type 620 This document requires allocation of a sub-TLV from the registry 621 "Pseudowire Interface Parameters Sub-TLV Type". 623 The following value is suggested for assignment: 625 TLV type Description 626 0x0D Selective Tree Interface Parameter. 628 8. Acknowledgment 630 Authors would like thank Kamran Raza, Andre Pelletier, and Parag 631 Jain for their valuable suggestions. 633 9. References 635 9.1. Normative References 637 [RFC2119] Bradner. S, "Key words for use in RFCs to Indicate 638 Requirement Levels", RFC 2119, March, 1997. 640 [RFC4447] "Transport of Layer 2 Frames Over MPLS", Martini, L., 641 et al., rfc4447 April 2006. 643 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 644 Specification", RFC 5036, October 2007. 646 [RFC5003] C. Metz, L. Martini, F. Balus, J. Sugimoto, "Attachment 647 Individual Identifier (AII) Types for Aggregation", RFC5003, 648 September 2007. 650 [RFC5331] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label 651 Assignment and Context-Specific Label Space", rfc5331, August 2008. 653 [RFC5332] T. Eckert, E. Rosen, Ed.,R. Aggarwal, Y. Rekhter, "MPLS 654 Multicast Encapsulations", rfc5332, August 2008. 656 [mLDP] I. Minei, K. Kompella, I. Wijnands, B. Thomas, "Label 657 Distribution Protocol Extensions for Point-to-Multipoint and 658 Multipoint-to-Multipoint Label Switched Paths", draft-ietf-mpls-ldp- 659 p2mp-06, Work In Progress, April 2009. 661 [RFC4875] R. Aggarwal, Ed., D. Papadimitriou, Ed., S. Yasukawa, Ed., 662 "Extensions to Resource Reservation Protocol - Traffic Engineering 663 (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs).", 664 rfc4875, May 2007. 666 [L3VPN-MCAST] R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, "BGP 667 Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", draft- 668 ietf-l3vpn-2547bis-mcast-bgp-08.txt, Work in Progress, October 2009. 670 [RFC5561] B.Thomas, K.Raza, S.Aggarwal, R.Agarwal, JL. Le Roux, "LDP 671 Capabilities", rfc5561, July 2009. 673 9.2. Informative References 675 [RFC3985] Stewart Bryant, et al., "PWE3 Architecture", RFC3985 677 [RFC6074] E. Rosen,W. Luo,B. Davie,V. Radoaca "Provisioning, Auto- 678 Discovery, and Signaling in Layer 2 Virtual Private Networks 679 (L2VPNs)", RFC6074, January 2011. 681 [P2MP-PW-REQ] F. Jounay, et. al, "Requirements for Point to 682 Multipoint Pseudowire", draft-ietf-pwe3-p2mp-pw-requirements-03.txt, 683 Work in Progress, August 2010. 685 [P2MP-LSP-PING] A. Farrel, S. Yasukawa, "Detecting Data Plane 686 Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS) 687 - Extensions to LSP Ping", draft-ietf-mpls-p2mp-lsp-ping-15.txt, 688 Work In Progress, January 2011. 690 [VPLS-MCAST] R. Aggarwal, Y. Kamite, L. Fang, and Y. Rekhter, 691 "Multicast in VPLS", draft-ietf-l2vpn-vpls-mcast-09.txt, Work In 692 Progress, July 2011. 694 Author's Addresses 696 Siva Sivabalan 697 Cisco Systems, Inc. 698 2000 Innovation Drive 699 Kanata, Ontario, K2K 3E8 700 Canada 701 Email: msiva@cisco.com 703 Sami Boutros 704 Cisco Systems, Inc. 705 3750 Cisco Way 706 San Jose, California 95134 707 USA 708 Email: sboutros@cisco.com 710 Luca Martini 711 Cisco Systems, Inc. 712 9155 East Nichols Avenue, Suite 400 713 Englewood, CO, 80112 714 United States 715 Email: lmartini@cisco.com 717 Maciek Konstantynowicz 718 Juniper Networks 719 UNITED KINGDOM 720 Email: maciek@juniper.net 722 Gianni Del Vecchio 723 Swisscom (Schweiz) AG 724 Zentweg 9 725 CH-3006 Bern 726 Switzerland 727 Email: Gianni.DelVecchio@swisscom.com 729 Thomas D. Nadeau 730 CA Technologies 731 273 Corporate Drive 732 Portsmouth, NH 03801 733 USA 734 Email: thomas.nadeau@ca.com 736 Frederic Jounay 737 France Telecom 738 2, avenue Pierre-Marzin 739 22307 Lannion Cedex 740 FRANCE 741 Email: frederic.jounay@orange-ftgroup.com 743 Philippe Niger 744 France Telecom 745 2, avenue Pierre-Marzin 746 22307 Lannion Cedex 747 FRANCE 748 Email: philippe.niger@orange-ftgroup.com 750 Yuji Kamite 751 NTT Communications Corporation 752 Tokyo Opera City Tower 753 3-20-2 Nishi Shinjuku, Shinjuku-ku 754 Tokyo 163-1421 755 Japan 756 Email: y.kamite@ntt.com 758 Lizhong Jin 759 ZTE 760 889 Bibo Road, 761 Shanghai, 201203 762 P.R.China 763 Email: lizhong.jin@zte.com.cn 765 Martin Vigoureux 766 Alcatel-Lucent 767 Route de Villejust 768 Nozay, 91620 769 France 770 Email: martin.vigoureux@alcatel-lucent.com 772 Laurent Ciavaglia 773 Alcatel-Lucent 774 Route de Villejust 775 Nozay, 91620 776 France 777 Email: Laurent.Ciavaglia@alcatel-lucent.com 779 Simon Delord 780 Telstra 781 E-mail: simon.a.delord@team.telstra.com 783 Full Copyright Statement 785 Copyright (c) 2010 IETF Trust and the persons identified as the 786 document authors. All rights reserved. 788 This document is subject to BCP 78 and the IETF Trust's Legal 789 Provisions Relating to IETF Documents 790 (http://trustee.ietf.org/license-info) in effect on the date of 791 publication of this document. Please review these documents 792 carefully, as they describe your rights and restrictions with respect 793 to this document. Code Components extracted from this document must 794 include Simplified BSD License text as described in Section 4.e of 795 the Trust Legal Provisions and are provided without warranty as 796 described in the Simplified BSD License. 798 All IETF Documents and the information contained therein are provided 799 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 800 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 801 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 802 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 803 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 804 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 805 FOR A PARTICULAR PURPOSE. 807 Intellectual Property Statement 809 The IETF takes no position regarding the validity or scope of any 810 Intellectual Property Rights or other rights that might be claimed to 811 pertain to the implementation or use of the technology described in 812 this document or the extent to which any license under such rights 813 might or might not be available; nor does it represent that it has 814 made any independent effort to identify any such rights. 816 Copies of Intellectual Property disclosures made to the IETF 817 Secretariat and any assurances of licenses to be made available, or 818 the result of an attempt made to obtain a general license or 819 permission for the use of such proprietary rights by implementers or 820 users of this specification can be obtained from the IETF on-line IPR 821 repository at http://www.ietf.org/ipr. 823 The IETF invites any interested party to bring to its attention any 824 copyrights, patents or patent applications, or other proprietary 825 rights that may cover technology that may be required to implement 826 any standard or specification contained in an IETF Document. Please 827 address the information to the IETF at ietf-ipr@ietf.org. 829 The definitive version of an IETF Document is that published by, or 830 under the auspices of, the IETF. Versions of IETF Documents that are 831 published by third parties, including those that are translated into 832 other languages, should not be considered to be definitive versions 833 of IETF Documents. The definitive version of these Legal Provisions 834 is that published by, or under the auspices of, the IETF. Versions of 835 these Legal Provisions that are published by third parties, including 836 those that are translated into other languages, should not be 837 considered to be definitive versions of these Legal Provisions. 839 For the avoidance of doubt, each Contributor to the UETF Standards 840 Process licenses each Contribution that he or she makes as part of 841 the IETF Standards Process to the IETF Trust pursuant to the 842 provisions of RFC 5378. No language to the contrary, or terms, 843 conditions or rights that differ from or are inconsistent with the 844 rights and licenses granted under RFC 5378, shall have any effect and 845 shall be null and void, whether published or posted by such 846 Contributor, or included with or in such Contribution. 848 Acknowledgment 850 Funding for the RFC Editor function is currently provided by the 851 Internet Society.